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* indicates a change was made in response to an item (Sometimes the * is before the comment 
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number and sometimes it follows the number,) 

These public review comments are included in this document, ordered by;X3J4 document number. 
96-0384 Comments on I SO/I EC CD 1989, Prog lang COBOL (Silletti/Wallace) 
! 96-0389 Crnts on CD 1989, Prog lang COBOL; IBM Part 2 (Silletti/Wallace) 
• 96-0412 - public review comments from David DeJongh 
; 96-0414 - public review comments from Raymond Obin 
1 96-0428 - public review comments from Lee Hansen 
I 96-0429 - public review comments from Charles Townsend 

considered 96-0442 and 96-0441 as part pf this comment 
i 96-0430 - public review comments from Ronald Silletti - Part 3 
i 96-0446 - public review comments from Ronald Silletti - Part 4 
) 96-0447— public review comments fro 
[ 96-0458 ^pyblic review comments fro 
96-0461 - public review comments from Jeffrey Fri 

public review comments from Don Schricker* • ; 
OO public review comments from Don Schricker 1 ! 

public review comments from Ronald Silletti - Part 1 3 
public review comments fromjponald Silletti — Part 14 / jjU ' 
public review comments fronrT^os^QSg|^J^ -4J^C /*^' 
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96-0487 
1 96-0488 
1 96-0489 
i 96-0490 
1 96-0493 

96-0500 
f 96-0502 
i 96-0506 



public review comments fromlgofL ^. 

public review comments from RiroSWletti - Part 11 
public review comments from Ronald Silletti - Part 10 
public review comments from Ronald Silletti - Part 5 
public review comments from Ronald Silletti - Part 9 
public review comments from Ronald Silletti - Part 7 
public review comments from Ronald Silletti - Part 8 
public review comments from Wataru Takagi % 
public review comments from Ronald Silletti - Part 6 
public review comments from Ronald Silletti - Part 12 
public review comments from Clark Morris 
public review comments from Ronald Silletti - Part 1 5 
Public review comments from Micro Focus (Gilbert/Gamble) 
Public review comments from Ronald Silletti - Part 16 
Public review comments from Jonathan Beit-Aharon 
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96'-0384 



Silletti (IBM Corporation) 



I i I Length of figurative constant^Rx^draft does not specify tbHength of a figurative constant when used in 



a concatenation egression. IBM has submits 
the document. 



it X3J4/05-O342 to Technical Committee X3J4 to amend 



X 



Response: Accept The length otaiSgurative constant in a cortcst^rVation expression was specified 
| i as one in 97-0218, Length c^Mftjurative constants in concatenation expressions, which was 



I approved by J4 at meeting 208. 



Add four methods (I can't think of any pleasing names) similar to the methods ot Comparable, ajnnvanani, 
. buNdnch ignore upper/lower case for the purposes of the comparison. 

i ,f X. y 

3. ■ I'm a bit abturbed by the absence of any streaming methods on an object for the purposes ofpxtemalization and 
subsequent reconHhution. These protocols might be used on transient (non-named) objects, ndt just formally 
persistent objects.) 

4. jp 587, 16.3.1.1. Why i^sOccurrencesOf" not invariant? How does this methodpafaiify the collection self? 
Same comment for List (p 63>>^6.3.t6.1). 

5. P623, 16.3.14.1. Why is "Intersfe^ion" structurally different from all tj^th'cr operations that produce a 
changed IdentitySet, for example, UniohS Is it just so that the postconditions can be stated neatly? 



Suggestion. Change to ... 
, jAnldentitySet Intersection* using Another 
linstead of ... 



AnldentitySet "Intersection" invariant using ^tfwherreturning Anlntersectiorl 
6.! P 625, 16.3.14.6.1. Change "method^tfis-subser to "... Is^sef. 
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7 I P 633. 16.3.16. t. Method "SubJ&T should be invariant, right? Justlfke "OccjrrencesOf". 

: | / X. 

8. ' Both national character handling and internationalization are important aspeste that must be 
addressed. Dependencies if any, on the environment of the invoking routine neeiKto be specified. 

i ^ 1 x 

It's 'not clear hpvfcollating sequences are managed, even with respect to.non-intematiorafeed 
erivironrpeif^ Is the collating sequence in the library always the one in effect at' the time onavocation. 



thus^quiring the library to be an "internationalized" implementation with respect to collating se< 
W* are the different character types handled (alphanumeric and national)? 



ce? 



^ 9CJ-0478 - public review comment 





Here are some comments on your draft Cobol-97 standard. TTiey are ift Joiir drtegorjes: Jfljat^SttWaiUiyj 
date-related); then editorial suggestions dealing with: Miscellaneous, your Substantive-Changes-Not-Affecting list, 
/ Validate. : 



an 



1 1 ■ 
You needn't write me anything but the briefest note about your action on this letter, you have too much other work 

tojdo. 

A-\ t . ; 1 Substantive:,,, 

I . ( To facilitate Year-2000 conversion-testing, allow th<@^S^^?A|?- s P ccial ** ^ 

modified and tested-to-see-if-modified. (John Piggott suggested the first of these.) I guess the SET statement 
cojJld be used for the first purpose. For the second, iF would interrogate a new special register that would be either 
a True/False "indicator* or a backup location like TRUE-CURRENT-DATE or;SA VED-CURRENT-DATE or 
AQRJAL-CURRENT-DATE. And perhaps there should be some standard way to restore CURRENT-DATE to its 
original status. 



Response: Reject. 

2 -i 

date forms, such 



ill assist Year-2000 migration by removing an obstacle to the use of compact 
regorrS!! .INTEGER format used by COBOL's Functions, and the new Packed and Binary 
formats that various Year-2000 vendors and writers are proposing. The obstacle is that such, formats are harder to 
download to the PC, which has caused some authorities to advise against convening to them. (Eg., See Tick Tick 



'■ I "\ 
November5, 1997 A o Document: J4/97-0318 

II . pFnOft^V P age41of107 

Tick, Jfinitr *95, page 8, col. 3.) So donl drop it if someone pcfil^SSPIrrVQ^^i areas it may have. Resolve 

such questions of interpretation in a subsequent Year-2000 task g^fflfiR'nlmtem). 

J j 

Response: Accept The FORMAT clause is retained. 

3a. j Consider setting up a Tajsk Grouplo interface with persons and organizations dealing witl? the Year-2000 
Problem, in case there are other changes like the above that could be implemented as Addenda, or at least so that 
vendor extensions c ould be coordinated and informally standardized. Most of the work could/should be done on 
the Internet, with a special extra site for private (inter-member) task group communications. At a minimum, such a 
task group could consider minor twiddling like the CURRENT-DATE adjustments^ proposed in Item I, above. 
More substantial enhancements might well be considered, either as a result of user pressure and/or of the 
opportunity to make a buck by offering a desperately needed service. It may be that these enhancements will come 
too late to help most users. Still, they will help some, and they will enable those applications that have been de- 
activated as a result of "triage" to be reactivated, since less work and (especially) no file conversion will be needed 
to gerjthem running. The enhancements I have in mind include: 

Response: Reject. There are already a number o f task groups in the industry. 

3b j j An extensive family of built-in^^^^^^^gnc^M In (8405 1) 



RKfWP Date-Handling Functions, I suggested (in- addmbnlo suggesting the curreht'daterconversion functions) a 
day-counting (between dates) function and a date-comparison function, both of which cojuld accept operands in 
different formats. Those two basic items could be added in an addenda, I trust Beyond Jhem are more 
sophisticated routines that really ought to be made available—there's certainly a demandtfor them. There are now 
several vendors offering date-routine collections, including holiday tables that work bodi domestically and/or 
inteijnarJonally. (User adjustments to them are possible too.) Perhaps one of these venders would agree to license 
his! product at a low rate to those implementors who prefer to buy rather than build. (Such inexpensive license- 
abiljty is commonly considered when ANSI hardware standards are developed, so I extrajpolate that it's OK for 
software too, at least in an emergency. Alternatively, end-user sites could be asked to contribute their date routines 
tojthe TG. E.g., as I wrote in (83030) RK-WP Suggestion Smorgasbord, Item 9: : "I believe Boeing has a collection 
whjch will handle everything but Mayan.") 

The advantages of making these intrinsic functions are efficiency, reliability, simplicity (fewer CALLs and 

CCjPYs), inter-shop standardization (hence reduced training costs and merger-time nightmares), etc. As a 

business-oriented language, inclusion of such business-oriented routines is acceptable — indeed, desirable. (Other 

business-savvy languages have such a data-type; cg^Clarion, as I mentioned 'way back When.) Year-2000 

conversion software could generate these functions and thereby upgrade users' software libraries in the process. 

Currently, code often comes back from such a conversion in a downgraded (patched-looking) state: In the Nov. '84 

minutes, p. 16, the CCC accepted only a subset of the date manipulation functions I had suggested^the other 

suggestions were implicitly rejected by consensus and not brought to a vote. ! 
' j i 
Response: These will be considered as an enhancement for future standard. 

3c A DA JE data-attribute Clc., a new clause) whereby a user can both specify an item as being a date and 
also indicate its format. This would be helpful to the date-comparison and day-counting functions suggested 
above; although in the absence of a date attribute, the functions could infer one from the item's PIC & USAGE. It 
uould also assist other date-related functions that might be added, as well as being helpful to the maintenance 
programmer and to COBOL-analysis software. Also, Year-2000 conversion software could insert this data- 
attribute on items it decides (in optional consultation with humans) are dates. 

In addition, the attribute could (if extensible) integrate the many idiosyncraticidate formats that now exist into 
standard COBOL in a nearly seamless way. E.g. t assume the keyword for the, attribute is *DATE-<suffix> H , where 
;standard terms for the most common "suffixes" (like JULIAN and YRMODA and YEARMODA) are built-in, and 
Nxhere other suffixes could be added on the fly. (Perhaps an interface could be provided that would allow user- 

wrinen (or ISV-written) routines to decode/encode other formats to dates with particular user-suffixes.) 

* I 

t jThe CCC voted down (10*7) using a data-attribute to handle the four date conversions it now provides in favor of 
functions in the Nov. '84 minutes, p. 16. 
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user-defined functions, and TYPEDEFs allow for user-defined date datatype. Consider the SQL date datatype and 



the 
3d 



full set of functions to access it 



A compiler directive (and/or a run-time ability) to se^^iiding window" for two-digit years. JTie 
compiler would then be able to adjust arithmetic operations ami comparisons and sorts on fields that use such an 
item to give the desired results. (In those (rare) cases where it can't figure out what's going on it could give up and 
let the user know he needs to clarify matters.]! This is important; it is now too late for much of the user community 
to make a gradual migration and associated file-expansion to a four-digit year. File expansion "terribly complicates 
tbej Year-2000 process; it expands the impact onto other programs that accept the files or screens produced, it 
impacts report formats, and (therefore) it expands the scope of what must be tested. Testing, including regression 
testing, is estimated to be the hardest part of the Year-2000 process. Imagine how hard it will be to create an entire 
new environment with a multitude of expanded files, databases, screens, reports, JCL,etc, and then to get the 
machine time to run realistic simulations. Many applications will simply be abandoned unless there is some way 
they can "work around" the year 2000 without file expansion. I 

J 'suggested this be done in (831 18) Tji^^^^ry ftoblem. hi received the "After discussion ... 

completed" treatment (» consensus r^^tiOT)lr?q^^S^^utes, p. 36. I repeated my suggestion, but only for 
a' function, in 8405 1 . It was rejected 1 4- 1 ; see Nov. '84 minutes, p. 16. At that meeting I distributed (with 
authorial permission) substantial photocopied extracts from Jerome Murray's Year-20(p alarm-book. Computers in 
Gqisis. I quoted his worldwide-conversion-cost estimate of $60 billion and got* a roomful of "get*outta-here" looks. 
IjKope, while there is still time for COBOL to be of some help to some users (which means it can save billions at a 
cost of ten-thousands) that action will be taken. If the CCC had acted as I suggested in *83 and *84, and had made 
that the ONLY change in Cobol-97, it would still have done more for the user community than with every other 
change it has provided— and by factor often. There> still time to provide a factor-of-one savings, so I hope it will 
be done. (Of course, file expansion can also be avoided if a four-digit year is used in a more compact form. The 
new bin ?j^S&^^ , : l gJ i J is » but *«y on| y g° I»rt way; in order to integrate such compressed date formats into 
COBOl45^DA^att^te Suggested above is needed.) (IVe consulted the|Cutter Info. Corp/s Survivingthe 
Vfar 2000 report, and the back issue set of Tick Tick Tick, in writing the above. Some of the authorities in those 
publications advocate avoidance of year expansion, so the position is not unreasonable.) 

Response: This will.be conddered asjin enlj aqp»m^T fft r a fojMrfy 



Page 249, paragraph 1*3. 15. 14.2, Rule 6, and General Rule 2 on next page— delete. (I assjjmesomeone is 
^klng^e^eleting items that deal with the ATTRIBUTE clause. (Too bad'; ifs possible to^ifptement it and it 
adds value toTU^.) Other locations affected include 8.3. LI 2.8 and 8.10.) 

Response: We accephfcu the book is inconsistent rTKel&lfsp^lficatkm of the. 



;inc 



(BUTE clause will be 



j*|5. Eliminate (or at least tone dowrt>^st^ve-Change-Np^ #81, "The contents of a character 
j position described with the PICTU^ch^^ not^KjSiired to be a letter". I was present in Chicago when 

; this was passed, 5-1, and I couldn't get a good justiTte^t^out of those in favor except that "it doesnt do anything 
land we're sick of it". My pointing out that Valid^e^ouW^na^e use of it and prove its inclusion to be far-sighted 



made no impression. (Fortunately General Rides 15A (292) andTtAM94) of Picture seem not to have been 
i modified. See also General Rule 3 of UJ/TOE, on page 336 and GeneraH^fc 3a of VALIDATE on page 497.) 
! The user community shouldn't be giyemthe impression, by this item, that PICA-is meaningless. 



■ 

, Response:. Accept 




Si'Ba^Jfc^rcfofd 



' Although ihttrire only editorial changes, this is the most "public" page of the standard; it conveys "whatY 
feature-wj$r, which is the public's main concern, via the press. Therefore it should be well-organized, error-free^ 
and confplete. , ' 



